🔹 前言

過去幾年，大家談 MLOps（Machine Learning Operations）時，重點都放在「如何讓機器學習模型可以產品化與維運」。 但隨著 GPT-4、LLaMA、Mistral 等大語言模型（Large Language Models, LLMs）的出現，我們發現：傳統的 MLOps 思維，已經不足以應付 LLM 的特性與挑戰。

於是，「LLMOps」這個詞開始流行，專門針對 LLM 的開發、部署與維運問題。

🔹 在開始之前，必須先瞭解...

這系列適合誰?

❌ 這系列不包含: 模型訓練、Transformer 原理、深度學習數學
✅ 你需要會: Python 基礎、Docker 基本操作(不需 ML 背景)

30 天完整學習地圖

💡 學習建議:

• 每天 30-120 分鐘 (含實作)
• 每週五檢查該週產出是否完成
• 建議邊看邊跟著 GitHub Repo 實作
• 完整程式碼: GitHub 連結

⚠️ 彈性閱讀: Week 1 打基礎後,可依職能挑選 Week 2-4 重點章節

❌ 這系列不適合:

• 想學 Transformer 原理的 AI 研究者
• 想做模型訓練/Fine-tuning 的 ML 工程師
• 沒有 Python/Docker 基礎的人

🔹 傳統 MLOps 的挑戰解法

在傳統 MLOps 中，典型流程是：

1. 資料收集與清洗 → DataOps
2. 特徵工程（Feature Engineering）
3. 模型訓練（Training）
4. 模型部署（Serving）
5. 模型監控（Monitoring & Retraining）

挑戰點：

• 資料持續變動（Data Drift）
• 模型效果衰退（Concept Drift）
• 訓練與推論資源需求高
• 需要 CI/CD for ML： MLflow, Kubeflow, TFX

🔹 為什麼 LLMOps 不一樣？

大語言模型跟傳統 ML 模型有幾個本質差異：

🔍 参考資料:
“From **MLOps to LLMOps: The evolution of automation for AI-powered applications”*（CircleCI，2024），指出，LLMOps 雖然沿用 MLOps 的基礎，但必須額外處理 治理、觀測性、成本控管、語言資料處理與即時響應，這也是為什麼需要新一套思維。

🔹 LLMOps 的核心要素

1. Prompt & Prompt Template 管理

   • 不只是模型 code，而是提示詞也需要版本化。

2. RAG Pipeline 維運

   • 文件切片 → Embedding → 向量資料庫 → 檢索 → 回答。
   • 要考慮資料更新、自動重建索引、效能改善。

3. 觀測性 (Observability)

   • 除了 latency/cost，還要監控 幻覺 (hallucination)、敏感資料洩漏、不當輸出。

4. 成本與資源控管

   • Token 成本 ≠ 免費，API 呼叫次數要控管。
   • Caching、Hybrid 模型（小模型先答，大模型 fallback）是常見策略。

5. 安全性與合規

   • Prompt Injection、防洩漏、防止濫用（特別是企業內部落地）。

🔹 舉例：客服問答系統的差異

📌 傳統 MLOps 的做法

假設公司要做一個「客服 FAQ 自動回覆系統」：

1. 收集歷史客服對話，整理成 問題–答案 資料集。
2. 用 TF-IDF / XGBoost / BERT 訓練一個分類器，判斷問題屬於哪個類別。
3. 部署模型到 API Server。
4. 每隔幾個月 retrain，避免因新產品上線而答案過時。

👉 特徵：資料量中等、可自己訓練、模型更新靠 retrain。

📌 LLMOps 的做法

如果我們用 LLM（例如 GPT-4o-mini）來解這個問題：

1. 不用訓練模型，直接丟 prompt：「你是客服助手，回答以下 FAQ 問題」。

2. 為了避免「亂回答」，要加上 RAG Pipeline：

   • 客戶問題 → embedding → 向量資料庫檢索 → 找到最相關文件 → 塞進 prompt。

3. 要做的維運工作是：

   • Prompt 管理（避免工程師改 prompt 後效果變差）。
   • 資料更新（新 FAQ 要即時進向量庫）。
   • 成本監控（每次 call API 都會花錢）。
   • 輸出檢測（避免回答「我們有 UFO 保固服務」這種幻覺）。

👉 特徵：不用自己訓練，但要處理 Prompt、資料、成本、輸出品質。

📝 小結

MLOps 解決的是「如何讓一個訓練好的模型持續運作」，痛點是「如何持續 retrain 模型」。
LLMOps 解決的是「如何讓一個巨大的、通常不是你訓練的模型，能在現實業務中 安全、便宜、穩定 地跑起來」，而痛點是「如何讓模型行為可控、可監控、可持續」。

換句話說：MLOps 解決模型壽命週期，LLMOps 解決模型「行為」的生命週期。

明天（Day02）我們要開始介紹這個系列的實作主線：「如何用 Free Tier + OpenAI API 打造一個企業知識庫 QA Chatbot」，並規劃我們的環境與工具組合。

📚 引用來源

• From MLOps to LLMOps: The evolution of automation for AI-powered applications
• Weights & Biases: What is LLMOps?
• Google Cloud: MLOps best practices